ci(release): Publish to Open VSX and automate releases with release-please - #20
Open
Cyclodex wants to merge 2 commits into
Open
ci(release): Publish to Open VSX and automate releases with release-please#20Cyclodex wants to merge 2 commits into
Cyclodex wants to merge 2 commits into
Conversation
…lease Cursor, VSCodium, Windsurf, Gitpod and Theia cannot use the Visual Studio Marketplace and install from the Open VSX Registry instead, so the extension was only reachable there by side-loading a .vsix (issue #18). Adds the release automation modelled on SoulcodeAgency/bexio-chrome-extension: release-please opens a Release PR on main, merging it tags + creates the GitHub Release and triggers publish.yml, which builds one .vsix and ships that same artifact to both registries. - release-please uses always-bump-patch, because VERSIONING.md reserves odd minors for pre-releases and an automatic minor bump would land on one; a minor is requested with Release-As in a commit body - the Open VSX step is skipped with a warning while OVSX_PAT is unset, so the Marketplace release still goes out until the Eclipse publisher agreement and the Soulcode namespace are in place - ci.yml gains workflow_dispatch as the fallback for the Release PR's parked build check, and a read-only token - package.json gains the missing license field, which Open VSX surfaces No extension code changes: the only marketplace touchpoint is the built-in workbench.extensions.search command, which Cursor implements. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ADtomv1AGke7LABz7GCD7d
Each cycle now produces two Release PRs, in order: the odd-minor pre-release (1.3.0) and the even-minor release (1.4.0) that follows it. Each PR is labelled and commented with the channel it will publish to. - publish.yml derives --pre-release from the parity of the minor in package.json instead of taking it as an input, so the version number and the published channel cannot disagree; the prerelease inputs are gone - a promote job opens the second PR by itself: once an odd-minor version is published it pushes an empty commit carrying Release-As for the next even minor and runs release-please again, because a push made with GITHUB_TOKEN does not start a new workflow run - .github/scripts/label-release-pr.sh labels the Release PR pre-release or release. It labels rather than renames on purpose: release-please parses its own PR title to recover the version when the PR merges, so editing the title risks breaking the release RELEASE.md documents the cycle, how to cut another pre-release during the soak, and the branch-protection caveat for the promotion push. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ADtomv1AGke7LABz7GCD7d
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes the distribution gap reported in #18: Cursor, VSCodium, Windsurf, Gitpod and Theia cannot use the Visual Studio Marketplace and install from the Open VSX Registry instead, so the extension was only reachable there by side-loading a
.vsix.No extension code changes were needed. The only marketplace touchpoint is
vscode.commands.executeCommand('workbench.extensions.search', ...)insrc/utils.ts:94, a built-in command Cursor implements; everything else is stablevscode.extensions.*API onengines.vscode ^1.74.0. This is purely a publishing change.The release cycle
Every cycle ships twice, and each shipment gets its own Release PR:
1.3.0pre-release--pre-release1.4.0releaseNothing anywhere asks which channel a release is — the version decides.
publish.ymlreads the parity of the minor out ofpackage.jsonand adds--pre-releaseon odd, so the number and the published channel cannot disagree. Theprereleaseworkflow inputs were removed for that reason.The second PR opens by itself: once the odd-minor version is published, the
promotejob pushes an empty commit carryingRelease-As: 1.4.0and re-runs release-please. It then sits there until you've soaked the pre-release long enough to merge it. You only write aRelease-Asby hand once per cycle, to open it (Release-As: 1.3.0).Full flow: merge
develop→main→ pre-release PR → merge → publishes pre-release → release PR appears → merge when happy → publishes release → back-mergemain→develop.Decisions worth reviewing
Labelled, not renamed. The PR title says
chore(main): release 1.3.0; the channel is carried by a label and a comment. That is deliberate — release-please parses its own PR title to recover the version when the PR merges ("must be able to parse out the component and version from the pull request"), so renaming it risks the release not being created at all. If you'd rather have the words in the title, it can be done viapull-request-title-pattern, but that pattern is static — it cannot say "pre-release" on one PR and "release" on the next.always-bump-patch. Nothing crosses a minor boundary on its own — an automaticfeat:bump would walk1.2.4 → 1.3.0and silently turn a release into a pre-release. Patch bumps stay inside their channel, which is what you want:1.3.0 → 1.3.1is another pre-release.Conventional commits are now required. The current style is
fix(Maintenance) Fixed types— no colon, which release-please cannot parse, so nothing would ever ship. CLAUDE.md now specifiesfix(maintenance): Message. This is the one change that silently breaks releases if it isn't followed.release-please watches
main, keeping git-flow. Cost is amain → developback-merge after each release.Two caveats documented in RELEASE.md: a
fix:landing during the soak folds into the pending release rather than cutting a new pre-release (useRelease-As: 1.3.1if you want one), and the promotion push needsmainto allowgithub-actions[bot]if the branch is protected.Changes
.github/workflows/release-please.ymlmain, channel labelling, publish, then thepromotejob that queues the release PR.github/workflows/publish.yml.vsix, publishes to both registries, attaches to the Release.github/scripts/label-release-pr.sh.github/workflows/ci.ymlworkflow_dispatch+ a read-only tokenrelease-please-config.json,.release-please-manifest.json1.2.4package.jsonlicensefield,ovsxpinned at 1.1.0,publish:openvsxscripts,release/pre-releasecover both registries.vscodeignoreCHANGELOG.mdso both registries render a changelog tabRELEASE.md,VERSIONING.md,CLAUDE.md,README.mdThe Release-PR-approval step in
release-please.ymlis carried over frombexio-chrome-extension, where 1.4.0, 1.5.0 and 1.6.0 all shipped without a build check before it existed.Before this can publish to Open VSX
The workflow skips the Open VSX step with a warning rather than failing while
OVSX_PATis unset, so Marketplace releases keep flowing meanwhile. To activate it (RELEASE.md → One-time setup):npx ovsx create-namespace Soulcode -p <token>.OVSX_PATas a repository secret (andVSCE_PAT, if CI hasn't published before).Optionally request namespace ownership on
EclipseFdn/open-vsx.orgso the extension shows as verified.Verification
actionlintclean on all three workflows;bash -nclean on the script1.2.4 / 1.3.0 / 1.3.1 / 1.4.0 / 1.10.2 / 1.11.0— double-digit minors includedvsce packageproduces a valid.vsixcontainingLICENSE.txtandchangelog.mdovsxchanged zero existing lockfile versions (74 added, 0 changed, 0 removed)Not verified: the workflows have not executed on GitHub —
release-please.ymlonly runs on a push tomain, so the first real cycle is the first live test of the promote job.